4.2.1 ガイド:要求エリア
要求エリアは、取引処理や新興市場など、顧客視点で論理的にまとまったプロダクトバックログアイテムのまとまりのこと
要求エリアごとに、個別の(小さい)LeSS の導入のように扱う
要求エリアに含まれるもの
エリアプロダクトバックログ
1 つのエリアに属するプロダクトバックログのサブセットのこと
個別のバックログではない
論理的にはプロダクトバックログを基とする 1 つのビュー
エリアプロダクトオーナー
顧客要求の論理的エリアを専門にする個別の「プロダクトオーナー」のこと
エリアプロダクトオーナーは、チームのプロダクトオーナーとして振る舞う
プロダクトオーナーチームの一員としてプロダクト全体思考を保つために、全体のプロダクトオーナーや、h家のエリアプロダクトオーナーと協力する(参考: 8.2 LeSS Huge) フィーチャーチーム
顧客の言葉で話ができる範囲でプロダクトの一部を専門とするチーム。各チームは、 1 つの要求エリアに含まれる
要求エリアは「8 チーム」以上にスケーリングするとき、 LeSS に追加する主要な構造である(同時に LeSS Huge にするということになる)
LeSS をスケーリングするときに起きる以下の問題を解決するために作られた構造
問題 1 : 大きすぎるプロダクトバックログ
1 スプリントあたり 1 チームが対応するアイテムを 4 つとして、 3 スプリント分が分割されて明確なアイテムになっていて、全体で 20 チームあるとする。すなわち 240 の詳細化されたアイテムがプロダクトバックログにあることになる
詳細化されたアイテムが非常に多くあるだけでなく、リファインメントされていないアイテムも多いため、プロダクトバックログは扱いにくくなる
問題 2 : プロダクトオーナーの手に負えなくなる
1 人のプロダクトオーナーが一緒に仕事ができるチームの数には、 5-10 チームの間に限界点がある
プロダクトオーナーが各アイテムの詳細な明確化に関わらず、優先順位付けや顧客、チームとのコラボレーションに集中している場合でも、 5-10 が限界
これ以上になるとプロダクトグループの内側と外側の両方に集中し、バランスをとることが持続可能ではなくなる
問題 3 : 多すぎるミーティング参加者
20 チームから 2 人のチーム代表が参加する大きなスプリントプランニングになる
この規模の会議では生産的かつ集中を保つのは難しい
問題 4 : チームが集中力を失う
チームはあまりにも頻繁に集中する対象を変えたり、広すぎる領域をカバーすると、不満がたまり生産性が下がる
顧客中心のエリアでチームを特化させることにより、生産的なチームを作るために必要な集中を作り出す
要求エリアの構造の例
https://scrapbox.io/files/649b9d4fd06fa1001bd4dd08.png
プロダクトバックログには、全てのプロダクトバックログアイテムが含まれていて、各アイテムはどれか 1 つの要求エリアに割り当てられる
それぞれの要求エリアには 1 人のエリアプロダクトオーナーがいる
それぞれの要求エリアに属する全てのアイテムがエリアプロダクトバックログとなる
各チームは、 1 つの要求エリアに長期間所属する
全体のプロダクトオーナーは、すべてのエリアのアイテムの価値をチェックする
エリア間の価値の差が大きすぎる場合、プロダクトオーナーはチームを別のエリアに移動することができる
このようにしてプロダクトオーナーはプロダクト全体の投資効果に集中できる